WEBVTT 00:00.000 --> 00:05.600 Hello everyone. So I'm Ben Fletcher and what I'm going to talk about today is turning policy 00:05.600 --> 00:12.360 into a wiki. So what I'm looking to cover is the background and in terms of the challenges, 00:12.360 --> 00:19.720 not only the challenges of how the policy was in its current state, but also the challenges 00:19.720 --> 00:28.360 of introducing a wiki and getting over a certain mindset. We're also going to look at why we 00:28.360 --> 00:33.880 chose the particular content management system, what its advantages were, what its disadvantages 00:33.880 --> 00:39.000 were and how we address those and how we address the concerns of stakeholders in terms of when 00:39.000 --> 00:45.320 you talk about turning a policy which is seen as quite a slow moving beast to a wiki which 00:45.320 --> 00:52.840 is conceived absolutely differently. How do you address those concerns? Then also our 00:52.840 --> 01:00.320 approach to developing the policy, so the methodology that we chose because when you're 01:00.320 --> 01:06.680 looking at this giant problem, it can be quite daunting and then the conclusions, observations 01:06.680 --> 01:10.760 and hopefully that'll be quite an interactive thing. So there'll be a lot of sort of hard 01:10.760 --> 01:17.760 truths that our stakeholders feel about media wiki, the semantic media wiki. So we'll put 01:17.760 --> 01:24.360 those out there, see what people think about them. So I've been 15 years in the Royal Air 01:24.360 --> 01:31.400 Force, actually in just over a week it'll be a 100 year anniversary and really I've 01:31.400 --> 01:38.240 been extremely fortunate, I've had a really interesting career. If I could tie down, whether 01:38.240 --> 01:44.000 it's been delivering coalition systems in Afghanistan or dealing with air surveillance 01:44.000 --> 01:49.760 systems in the UK, in a nutshell it's about getting the right information to the decision 01:49.760 --> 01:56.120 makers. So it is about moving that information, making sure the integrity of that information 01:56.120 --> 02:02.560 is there for the decision makers to make those operational decisions. So when I was given 02:02.560 --> 02:06.720 policy I wasn't overly happy, I'll be honest with you, I didn't really join the Air Force 02:06.720 --> 02:15.000 to do policy but I looked at it as the same problem, it is about getting the right information 02:15.000 --> 02:24.640 to the right people and how can we best do that. It was also that I was probably the 02:24.640 --> 02:28.680 sixth person in about five years who was trying to address this problem, it was a complex 02:28.680 --> 02:36.000 problem, it wasn't easy and really what we wanted to do was go back to basics, why was 02:36.000 --> 02:42.680 a policy struggling to keep pace with ICT. 02:42.680 --> 02:49.800 So if I just talk briefly about how the policy worked, so as the JSP 604 as this is called, 02:49.800 --> 02:54.640 the Joint Service Publication, this was the defence manual for ICT and this is the defence 02:54.640 --> 03:03.880 manual for ICT. So it is about what delivery inside the services or external contractors 03:03.880 --> 03:12.280 have to adhere to for ICT to be delivered to the military. And the way initially this 03:12.280 --> 03:19.720 was done was we had a defence network, so in old school terms we had a network and you 03:19.720 --> 03:24.520 had to make sure that you would adhere to the policy or you were not allowed to join 03:24.520 --> 03:29.920 that network. So in simplistic terms we had a business requirement come in, you would 03:29.920 --> 03:34.360 have the architects, the case officers who were the people who assisted the delivery 03:34.360 --> 03:41.880 teams to adhere to the accreditation requirements and the delivery teams and they would work 03:41.880 --> 03:45.720 together to understand that business requirement and then what we had were network joining 03:45.720 --> 03:52.360 rules and these were specific rules that you had to adhere to and if you didn't you were 03:52.360 --> 03:57.760 not allowed to release that capability. And this formed a document which was a technical 03:57.760 --> 04:05.200 release readiness assessment and it was risk management, so you would have to adhere to 04:05.200 --> 04:10.920 a certain rule, certain aspects and there would be a red, green and amber in terms of 04:10.920 --> 04:17.800 have you adhered to that, are we accepting that risk to allow this capability to be deployed 04:17.800 --> 04:21.680 on the defence network. 04:21.680 --> 04:32.320 The way we wanted to, we saw a couple of flaws with this straight away, one was that it was 04:32.320 --> 04:39.440 difficult for project managers, the case officers to really understand their project time scale, 04:39.440 --> 04:44.280 what's the resources that they would have to put against the release of this capability. 04:44.280 --> 04:50.760 So the first thing we wanted to do was work out the agreed evidence along and what we 04:50.760 --> 04:56.280 chose was a generic project cycle, project phases and the reason we chose generic project 04:56.280 --> 05:00.160 phases is because we could then map that against whether it be Agile, whether it be Cadmid, 05:00.160 --> 05:04.240 whether it be Prince 2, so we didn't want to tie down to a methodology, what we wanted 05:04.240 --> 05:10.960 to do was create an open framework where we could map it across. 05:10.960 --> 05:15.960 So phase one was understanding that, the other key thing was understanding who the risk arbitrator 05:15.960 --> 05:23.360 was, so who was the person who wanted that evidence and so you could go to them and say 05:23.360 --> 05:28.520 look we won't be able to deliver that evidence, are you willing to accept that risk as the 05:28.520 --> 05:33.880 risk arbitrator and they could say no way and that would escalate further because of 05:33.880 --> 05:38.320 course there's an operational imperative sometimes to deliver capability, so we have to match 05:38.320 --> 05:43.400 the operational perspective in terms of why this capability is required over the security 05:43.400 --> 05:48.440 risks or whatever other risks there are in delivering a capability. 05:48.440 --> 05:53.800 I've put phase one and phase two because we're dealing with phase one at the moment, what 05:53.800 --> 05:58.200 we've also done is changed it to ICT joining rules instead of network joining rules because 05:58.200 --> 06:03.520 we've transitioned, we now purchase services, we procure services, so it's not about joining 06:03.520 --> 06:09.760 a network anymore, it's about the procurement of a service and the aspects of that service 06:09.760 --> 06:16.720 and how that's delivered, so if we're purchasing a cloud service, what are the rules that we 06:16.720 --> 06:20.560 have to adhere to or make sure that we align with. 06:20.560 --> 06:28.480 The phase two bit is what we'd ideally like to do is to have that single document of evidence 06:28.480 --> 06:34.560 that is following the growth of that capability as it's being delivered. 06:34.560 --> 06:39.680 So you've got a complete history of why that capability is delivered, what the conversations 06:39.680 --> 06:42.700 were, the concerns were and so on. 06:42.700 --> 06:47.600 That content management system in terms of tracking that body of evidence hasn't been 06:47.600 --> 06:52.560 decided yet, that's going to be the next phase. 06:52.560 --> 06:57.080 My cards are on the table, I clearly think MediaWiki would be a very good solution. 06:57.080 --> 07:02.560 There's other benefits in terms of SharePoint using Flow, in terms of getting those documents 07:02.560 --> 07:09.260 to the right people, so that's further discussion. 07:09.260 --> 07:16.520 In terms of the priority of tasks, the key thing we wanted to do was there were a lot 07:16.520 --> 07:22.280 of documents out of date and we weren't quite sure the history of them, so we wanted to 07:22.280 --> 07:26.440 make sure we tied down who the authors were, who owned those documents, who could we point 07:26.440 --> 07:29.940 at and say that's out of date, that needs to be updating or what do you mean by that, 07:29.940 --> 07:31.520 can you clarify that further. 07:31.520 --> 07:41.880 So really, and was that content still valid and relevant? 07:41.880 --> 07:48.000 Initially the 604 with the network joining rules became a very, had a very good reputation 07:48.000 --> 07:54.920 in terms of it absolutely ensured that what we deployed on the defence network was safe, 07:54.920 --> 07:58.200 robust and meet the specifications. 07:58.200 --> 08:02.960 It became a victim of its own success, so everybody wanted to add rules and the problem 08:02.960 --> 08:08.440 was that is then what happened was we were starting to delay the delivery of capability 08:08.440 --> 08:14.480 because we didn't, people, what I'd call is stovepipe thinking, so they were thinking 08:14.480 --> 08:18.240 and they were doing absolutely the right thing, they were saying this is really important 08:18.240 --> 08:25.080 that this rule is there because in the past somebody hasn't done it and we've seen that 08:25.080 --> 08:34.040 effect but what we didn't understand was the impact of introducing that rule, so if a project 08:34.040 --> 08:39.440 is made up of cost, time and functionality, what was the impact of cost and time, were 08:39.440 --> 08:48.040 they really worth it, was it really justified to add that extra process within it. 08:48.040 --> 08:53.040 The hardest thing to understand within the JSP 604 in its current state was the impact 08:53.040 --> 08:57.760 of change, if I change this one document, what's the ripple effect it has throughout 08:57.760 --> 09:02.600 this document and that was one of our greatest challenges and that stovepipe thinking I've 09:02.600 --> 09:09.080 talked about but if we focus on anything, the key thing was to speed up delivery, every 09:09.080 --> 09:13.920 change that we do within this policy, the first question we ask is how does that speed 09:13.920 --> 09:22.000 up delivery and I'm not saying step away from the security or step away from these other 09:22.000 --> 09:27.240 things but we need to speed up delivery, that is absolutely key, we need to get operational 09:27.240 --> 09:32.640 capability to frontline troops, that is what this policy is about in a nutshell, so how 09:32.640 --> 09:40.720 do we speed up that delivery. 09:40.720 --> 09:48.640 The reason it was so complex was it was 2000 pages, 90 PDFs of documents and you had to 09:48.640 --> 09:52.880 read, really you had to read the whole lot to understand the interrelationship between 09:52.880 --> 09:58.440 it, there was missing information, there was links out of date, there was, you know, what 09:58.440 --> 10:10.120 we've all experienced in terms of when you have your content within PDFs, so it was, 10:10.120 --> 10:14.160 you would have to spend probably a year, a year and a half to really go through them, 10:14.160 --> 10:18.240 really understand them, really understand those interrelationships and then you'd have 10:18.240 --> 10:22.360 to try and work out how to change, you know, what to change and what that impact is going 10:22.360 --> 10:28.960 to have, an incredibly complex, an incredibly complex problem and really, well, it'd be 10:28.960 --> 10:33.880 no surprise otherwise I wouldn't be here, we chose MediaWiki as the content management 10:33.880 --> 10:41.720 system and these were the advantages that we could see straight away, the history, seeing 10:41.720 --> 10:47.640 where the document was because of course somebody may contract against that policy at a certain 10:47.640 --> 10:55.240 point, so straight away we can tell them what that document was at that certain date when 10:55.240 --> 11:01.600 that contract was signed, open source means we have the ability to look at the code to 11:01.600 --> 11:09.000 make sure that we're content, that there's nothing nefarious going on, the single source 11:09.000 --> 11:15.440 of information, you know, the ability to trans-clude information is absolutely phenomenal, to be 11:15.440 --> 11:19.560 fair I didn't know what trans-clusion meant before I ever started MediaWiki and I use 11:19.560 --> 11:26.800 it on a daily basis just to try and show off but, you know, that ability to have that single 11:26.800 --> 11:32.600 source of information and use it multiple times is an absolute, is an absolute killer 11:32.600 --> 11:42.000 feature. Yeah, having the ability just to Google something with such a vast community, 11:42.000 --> 11:46.920 it makes all the difference, it saves us time having to write the manuals, our key thing 11:46.920 --> 11:50.600 about the manuals was don't write it if it's already there, only write the things that 11:50.600 --> 11:58.240 are unique to our wiki in terms of the manuals. Multi-platform obviously, low skill gap, although 11:58.240 --> 12:03.000 I will put high skill gap and we'll talk about that in a sec and also, you know, I had good 12:03.000 --> 12:10.880 friends in NATO who were very helpful when I was in that beginning learning curve as 12:10.880 --> 12:17.440 it were and actually the argument that NATO are using it and NASA are using it are used 12:17.440 --> 12:25.520 constantly, you know, that's a winning argument straight away. So it's very encouraging when 12:25.520 --> 12:35.760 you've got, you know, strong organisations like that sort of converging to the same solution. 12:35.760 --> 12:42.120 We've talked about security, well, you know, the ability to segregate users. Now actually 12:42.120 --> 12:47.800 for our wiki, the wiki will be eventually published on the internet, it is supposed 12:47.800 --> 12:51.480 to be out there for industry to be able to have a look at and understand what they have 12:51.480 --> 13:03.360 to adhere to. So in this sense, it's not required, but if phase two, where I talk about the tracking 13:03.360 --> 13:07.320 and the following of capability which will be capturing risks and all those sort of things, 13:07.320 --> 13:14.560 that's something we would have to keep separate. So, and also when you've got military civil 13:14.560 --> 13:19.120 servants, contractors, there's also lines of segregation there as well that you have 13:19.120 --> 13:26.640 to think about. So there is, you know, there is certainly this, a justification for working 13:26.640 --> 13:37.960 out an agreed way of segregating users. The, you know, it's no coincidence that Microsoft 13:37.960 --> 13:43.360 give our office free to schools, you know, that they've created generation who pick 13:43.360 --> 13:50.160 up Microsoft Word when they're older and straight away they can use it. You know, there's a 13:50.160 --> 13:54.560 lot of people who've got a lot of good things to say towards the policy who really struggle 13:54.560 --> 13:59.240 with editing on a Wiki and we need to address that. We want greater contributors, we need 13:59.240 --> 14:05.760 to make it, you know, visual editor, I'm not, you know, I'm not, I don't particularly 14:05.760 --> 14:09.720 like it, I quite liked going back to the, you know, the Wiki pages and just typing like 14:09.720 --> 14:14.640 that, but it's not about us, you know, we're converted. We need to get the next generation 14:14.640 --> 14:28.040 on board. And reputation of the Wiki is something, again, I will talk about. So, policy, static, 14:28.040 --> 14:35.400 you know, quite rigid Wiki. I don't know what it is about human psyche, but we do always, 14:35.400 --> 14:39.560 well, first of all, we hate change, that's an absolute given. And secondly, we always 14:39.560 --> 14:43.600 remember the bad things, you know, everybody tells you how horrific the internet is or 14:43.600 --> 14:50.280 how, you know, and everybody, you know, daily basis is probably a bit of an exaggeration, 14:50.280 --> 14:55.040 but certainly on a weekly basis, you know, every three or four days, you know, I'm asked 14:55.040 --> 14:59.240 how can you possibly put policy into a Wiki, somebody can just analyze it and so on. And 14:59.240 --> 15:02.840 we were discussing this last night, what we need to have is killer answers for that. Because 15:02.840 --> 15:07.880 we all know, you know, what you're doing is you're taking the Wikipedia example where 15:07.880 --> 15:13.480 you can have anonymous editing. You know, I can see everybody who makes a change and, 15:13.480 --> 15:18.040 you know, the other thing is I'd be seriously worried about my organization if somebody 15:18.040 --> 15:22.800 is going around vandalizing the Wiki. So, I think we'd have a far greater problem than 15:22.800 --> 15:27.080 that. It actually, I think if somebody put it, it would highlight probably greater issues 15:27.080 --> 15:34.480 that we probably needed to know about anyway. But it's, you know, the, we need to address 15:34.480 --> 15:41.240 that because Wiki I think has, unfortunately, the name Wiki has a poor reputation that needs 15:41.240 --> 15:44.760 to be addressed. 15:44.760 --> 15:54.800 So, what I want to talk about now, so, you know, I've convinced the chain of command 15:54.800 --> 15:59.840 that a Wiki is where we should go and I've also shown them the advantages of semantic 15:59.840 --> 16:04.560 media Wiki and how we can actually start to database our knowledge and put it forward. 16:04.560 --> 16:10.920 So this is, it's quite a good diagram, it's a very good diagram. It's from a joint defense 16:10.920 --> 16:18.240 publication and it's called the Information Management Bridge as you can read. And we've 16:18.240 --> 16:22.800 got this vast, we've got this vast policy and, you know, what we're talking about is 16:22.800 --> 16:28.040 we want, we want to be in this space. We want to enable decision makers to make decisions. 16:28.040 --> 16:31.860 So it talks about the infrastructure obviously, we understand that. And then this managing 16:31.860 --> 16:39.360 of information and the exploitation and so on and really, so it's, it's implying that 16:39.360 --> 16:42.560 you need to get your information management right and obviously the infrastructure and 16:42.560 --> 16:49.760 all those sort of things. But I actually think that's the wrong approach. And I'll tell you 16:49.760 --> 16:56.360 about this bridge. Does anybody know this bridge? Yeah, Fourth Rail Bridge. So, when 16:56.360 --> 17:00.840 they used to paint it, they would start at this end and it'd take them about four years 17:00.840 --> 17:05.920 and they'd get to this end. And guess what they had to do? They had to start again. So, 17:05.920 --> 17:09.640 you know, and then the term is, you know, it's like painting the Fourth Rail Bridge. 17:09.640 --> 17:15.240 And that's what I think, sadly actually science has ruined this, they've now developed a fifteen 17:15.240 --> 17:19.320 year lasting paint, it's quite upsetting, but it's still a good, it's still a good, 17:19.320 --> 17:30.000 it's still a good sort of analogy. What I'm saying is start at this end, okay, so start 17:30.000 --> 17:35.840 at what do your decision makers need? What is the first thing? What's the most, prioritise 17:35.840 --> 17:41.040 the things they need? Start at this end and say, right, you need this, that breaks down 17:41.040 --> 17:45.720 into this database schema, whatever you want to call it, and then gets to go here. Don't 17:45.720 --> 17:50.400 start trying to boil the ocean, paint the Fourth Rail Bridge, you'll never finish. Get 17:50.400 --> 17:56.840 here, this is where you're adding value to the organisation. So, what is it you need? 17:56.840 --> 18:00.720 Right, we can do that. What's the next thing you need? Well, actually we've done half of 18:00.720 --> 18:08.520 that the first one. So, to me it's, don't get stuck in that space, it's basically, and 18:08.520 --> 18:14.520 you know, I've seen tragic situations where people who are trying to do the right thing 18:14.520 --> 18:18.440 with information management creating these sort of, slightly draconian rules on how you 18:18.440 --> 18:24.320 manage information. And they're, the concept is correct, you know, if you've got it all 18:24.320 --> 18:27.280 within, we can search it and all that sort of thing. But actually what it starts doing 18:27.280 --> 18:31.640 is impacting the decision makers because they're having to adhere to these draconian rules 18:31.640 --> 18:36.400 without actually people thinking about, you know, what are we trying to achieve? We want 18:36.400 --> 18:51.920 to be at that sharp end enabling those decisions. Quick win. Yeah, absolutely. So, it's agile. 18:51.920 --> 18:59.120 What's that, sorry? Yeah, absolutely. So, perfection's the enemy, good. I mean, we say, 18:59.120 --> 19:05.720 you know, good is good enough. You know, let's get out there, let's deliver in an agile way. 19:05.720 --> 19:08.960 Let's get those prototypes. So, I talked about right at the beginning, the most important 19:08.960 --> 19:13.680 thing we needed was we needed to understand who the stakeholders were within the document. 19:13.680 --> 19:19.200 So, straight away, we created little info boxes. I know you'll laugh at my, you know, 19:19.200 --> 19:24.800 my basic attempts at semantic media if you want, you know, but the first thing was, you 19:24.800 --> 19:30.880 know, who owns that page? You know, who's the author? Who's the owner? So, we can go 19:30.880 --> 19:34.520 and point to them and say, look, you haven't updated this and so on. You know, do you actually 19:34.520 --> 19:41.720 mean this? So, we had people that we could actually nail down and say, from that, we 19:41.720 --> 19:48.200 built the stakeholder pages. So, and this is absolutely critical because like most organisations, 19:48.200 --> 19:54.400 we're in constant, we're constantly changing. You know, we're looking at how we can reorganise, 19:54.400 --> 19:59.480 reorganise the business. Straight away, we can say, well, if you get rid of, if you get 19:59.480 --> 20:03.600 rid of this team, they're responsible for this. You know, that is your decision, but 20:03.600 --> 20:09.080 please understand the impact. So, we straight away could now show the impact of change to 20:09.080 --> 20:14.040 the business. They, as a handover, they could see straight away what they're responsible 20:14.040 --> 20:23.320 for within the policy and understand those areas as well. So, it benefited in both ways. 20:23.320 --> 20:27.980 I talked about the project plan. So, what we started doing was, you know, mapping it. 20:27.980 --> 20:33.040 We wanted to try and be as agile as possible and then what we could do was relate what's 20:33.040 --> 20:41.120 those bits of evidence that you have to produce when, who is the arbitrator of that risk? 20:41.120 --> 20:46.320 So, straight away, they've got a better idea of the resources they require, what they need 20:46.320 --> 20:59.000 to produce and when they need to produce it. I talked about the policy becoming a victim 20:59.000 --> 21:05.300 of its own success in terms of people adding these rules and not really understanding the 21:05.300 --> 21:12.120 impact of cost and time to the delivery. We identified 60 documents that people would 21:12.120 --> 21:19.120 have to produce for the delivery of capability. Now, what we started going back to and saying 21:19.120 --> 21:25.120 is do you actually require that document or what is it you're asking for within that document? 21:25.120 --> 21:29.120 And so, what we started building was a body of evidence. And actually, you found a lot 21:29.120 --> 21:35.000 of the rules, a lot of the risk arbitrators were asking for the same thing, just in different 21:35.000 --> 21:41.400 words. So, we're now looking at how we absolutely nailed down our taxonomy. So, we're asking 21:41.400 --> 21:48.040 for the same thing, the evidence produced and then we have this single document which 21:48.040 --> 21:52.360 is about the capability and all of that evidence captured on there with the discussions there. 21:52.360 --> 21:56.760 So, you've got, you understand why this was delivered, why risks were taken, why decisions 21:56.760 --> 22:07.920 were made. So, I come from a cyber security background and we've got, it always comes 22:07.920 --> 22:15.320 back to this, the CIA triangle, confidentiality, integrity and availability. And we have to 22:15.320 --> 22:22.120 be really, really careful that we're not burdening the project managers so much that we don't 22:22.120 --> 22:27.080 ever deliver a capability, you know. So, how do we get that? I'm not saying release a system 22:27.080 --> 22:33.680 that is dangerous to, you know, to other systems, but let's understand that risk and that's 22:33.680 --> 22:38.280 what we're trying to do. We're trying to better understand and articulate that risk of capabilities 22:38.280 --> 22:45.200 being brought into the military. We're absolutely key for this. It's, we're throwing things 22:45.200 --> 22:50.760 out there, agile delivery, get it out there, see what people say. You can't, you can spend 22:50.760 --> 22:56.440 too long speculating on what should be delivered. Get it out there, let people throw spears 22:56.440 --> 23:00.560 at it, but actually if they're throwing spears at it, they're showing an interest. So, it 23:00.560 --> 23:03.720 means they care. So, now you've got another stakeholder who's going to help you develop 23:03.720 --> 23:12.720 this and drive it forward. Change process is actually quite difficult. You can change, 23:12.720 --> 23:17.480 you know, you could change one word, you could put no, not or something, you know, and it 23:17.480 --> 23:24.880 could change the whole context of that page. So, it's something that we're sort of trying 23:24.880 --> 23:30.240 to grasp, but we've tried to break it down in terms of minor changes are just within, 23:30.240 --> 23:33.920 just changing the wording or whatever, the grammar within the page or if the teams have 23:33.920 --> 23:41.640 changed names. Significant change is basically you're making a change in that page, but it 23:41.640 --> 23:47.600 has an impact on at least another page. So, therefore, we want a larger number. So, we 23:47.600 --> 23:51.720 called ourselves the curators. I was very keen to make myself called a curator, so I 23:51.720 --> 23:58.960 didn't have to write any of this. I just designed it. I let other people write policy. So, day 23:58.960 --> 24:02.680 to day business, we want to give them mission command. We don't want to be, you know, we 24:02.680 --> 24:08.600 don't want to be holding their hands the whole time, but once a change starts stepping outside 24:08.600 --> 24:15.400 of their area, they need to start telling us. If it's a major change, i.e. you're completely 24:15.400 --> 24:23.640 redesigning that page, what we do is we create a draft page. So, we put it in a draft namespace. 24:23.640 --> 24:27.720 We allow all those discussions to go on there. We have a release process, and then we'll 24:27.720 --> 24:39.840 do a large changeover. I have to say analytics. So, some of the people we had to convince 24:39.840 --> 24:44.600 were government digital services. Actually, they were fully on board. They liked the fact 24:44.600 --> 24:52.320 that we were looking at other technologies for the hosting of policy. And, you know, 24:52.320 --> 24:59.280 we're getting contacted probably, you know, on a weekly basis by other policy, by other 24:59.280 --> 25:06.880 policy owners asking us how we're doing it and how we're overcoming some of the challenges. 25:06.880 --> 25:12.520 Analytics is key because we need to quantify the evidence. We believed there were a lot 25:12.520 --> 25:17.520 of people going on our pages, but we also wanted to understand how people were going 25:17.520 --> 25:35.560 through the document. On the front page, you'll see I had... That took me ages. I know it's 25:35.560 --> 25:40.480 only four buttons, but that took me ages to work out because, first of all, we had lots 25:40.480 --> 25:46.440 of links on the pages. But I wanted to narrow down. If you think that people can only memorize 25:46.440 --> 25:50.880 seven things, you know, the average human can only memorize seven things. The rule is 25:50.880 --> 25:56.120 you shouldn't have more than seven things there. We wanted to consider all the stakeholders 25:56.120 --> 26:04.560 and work out which way they're going to go into the document. You know, it's trying to 26:04.560 --> 26:11.640 make it as simple as possible for the users just to basically drill down into that information. 26:11.640 --> 26:17.840 But this was telling us how people's route through the Wiki, how long they spent on 26:17.840 --> 26:30.360 certain pages. Really, really useful. So observations, the controversial bit. Okay. So some of these 26:30.360 --> 26:35.160 are my opinions, some of these are stakeholders' opinions, but these are opinions that have 26:35.160 --> 26:44.560 been put out there. Okay. Style. A lot of people, when you're trying to sell a Wiki 26:44.560 --> 26:50.800 to your bosses, it could do with looking a bit slicker. You know, I'm just throwing it 26:50.800 --> 26:57.800 out there. You know, I think it looks a bit Microsoft XP. You know, it's... And some people 26:57.800 --> 27:04.120 like the way it looks. I think they could... Style could certainly... It's a sad thing, 27:04.120 --> 27:09.560 but aesthetics are a major factor in people choosing capability. It shouldn't be, but 27:09.560 --> 27:17.240 it is. Editing. As I've said before, we need to capture... We're asking people to spend 27:17.240 --> 27:24.160 their time giving us their knowledge. We need to make it as easy for everybody as possible. 27:24.160 --> 27:29.320 Right. We need to have some killer answers to, can't anybody come up and wipe off all 27:29.320 --> 27:36.840 your data? You know, these standard questions. Semantic Media Wiki is really, really difficult 27:36.840 --> 27:43.400 to understand, and we need to... It took me a long time to really understand the benefits 27:43.400 --> 27:48.720 of Semantic Media Wiki. Now I'm blown away. It's absolutely phenomenal, and I show demonstration 27:48.720 --> 27:54.520 pages and so on, but it's not doing itself any favors because it is not selling itself 27:54.520 --> 28:02.920 as well as it could. Visualizing information. So people are getting lost in our Wiki. You 28:02.920 --> 28:07.800 know, the ability just to have what page links... You know, an easy way of doing it. I know 28:07.800 --> 28:12.200 there's lots of ways of doing it, but an easy way to show where you are within the document 28:12.200 --> 28:17.600 and how you got there and who the parent is, who the child is. You know, something simple 28:17.600 --> 28:26.600 would be, again, absolutely very useful. Right. What are the unique selling points of Media 28:26.600 --> 28:31.160 Wiki? What are the unique selling points of Semantic Media Wiki? We need to get that information 28:31.160 --> 28:35.000 out there. We need to put that in frequently asked questions. So somebody comes up to me. 28:35.000 --> 28:40.280 I've got 10 seconds to sell to them. What Semantic... You know, what it does, you know, 28:40.280 --> 28:44.280 let's have it between us. You know, there's lots of wordsmiths. Let's come up with some 28:44.280 --> 28:50.560 really catchy... In business speak, how are we going to sell this? Developer environments. 28:50.560 --> 28:55.000 The next generation, you want people just to be able to jump onto something. It is way 28:55.000 --> 29:02.400 too complicated to download stuff, to download the extensions. We all accept that. It's... 29:02.400 --> 29:07.000 If we want people... If we want people to become more stakeholder... You know, the saying 29:07.000 --> 29:12.000 is for every pair of hands, you get a free brain. Okay? So the more people we get just 29:12.000 --> 29:17.960 playing around with it on sand pits and everywhere, the more people we will have starting contribute. 29:17.960 --> 29:26.080 We all understand the benefits of increasing the organization. Recipes, you know, there 29:26.080 --> 29:32.600 are standard things. We've actually put them... So that website, the Enterprise Media Wiki, 29:32.600 --> 29:40.880 we started putting them down. Things like meeting records. Things like bug trackers, 29:40.880 --> 29:44.120 free logs, those sort of things. We can create those little recipes. How do you create them? 29:44.120 --> 29:47.600 Bang, straight away, you've got a 10-minute instruction of how I can now build that onto 29:47.600 --> 29:52.200 my Wiki. You know, let's start building best examples and showing people and just giving 29:52.200 --> 29:56.920 them step-by-step guides of how you deploy that onto your system. Because straight away, 29:56.920 --> 30:03.720 you're giving them a prototype to show to their bosses. Yeah. Bundle extensions. You 30:03.720 --> 30:08.480 know, just give me something double-click install done. You know, if you want, build 30:08.480 --> 30:12.320 it around business personas. If it's an engineering company, if it's a marketing company, doesn't 30:12.320 --> 30:20.400 matter. But let's put it all together and just sell it out there. Security layers. The 30:20.400 --> 30:26.560 more I think about security layers, because we had a lively discussion about it yesterday, 30:26.560 --> 30:30.560 it is really complicated because it's the aggregation of data that can increase the 30:30.560 --> 30:38.240 classification of... And that is very difficult to understand. So the more I think about splitting 30:38.240 --> 30:44.400 a Wiki, the more difficult I think that is. And I think, actually, you need to talk about 30:44.400 --> 30:50.600 deploying separate Wikis and blocking those links in between. I don't know, okay? But 30:50.600 --> 30:56.720 amongst us, the solution is in this room. So what we need to do is to put a white paper 30:56.720 --> 31:03.720 out of this is our solution to security layers. There's absolutely a business case for that. 31:03.720 --> 31:11.000 And if we can put forward what we think is the best solution, that enables people to 31:11.000 --> 31:19.640 say, this is how we would do it in this circumstance. We talked about crossing the chasm, okay? 31:19.640 --> 31:26.880 Media Wiki. So I don't know if you've seen this. It is about how you jump from being 31:26.880 --> 31:34.640 a... Just jumping to be a mainstream capability that people use. And they talk about the 14%. 31:34.640 --> 31:39.880 So you want to get past the early adopters, and that's when you're into the money if you're 31:39.880 --> 31:46.520 a business or so on. So you're trying to jump that 14%. And I've put just because it's open 31:46.520 --> 31:51.040 source doesn't mean it shouldn't behave like a proprietary software, shouldn't look at 31:51.040 --> 31:55.040 how it can market itself, shouldn't look at... There's nothing wrong with looking at other 31:55.040 --> 31:59.800 capabilities and saying, they do that well, how could we do that? How could we replicate 31:59.800 --> 32:03.560 that? There's some things that the Media Wiki is not meant to do, but there's other things 32:03.560 --> 32:08.760 to go, actually, we could do that. We could probably do that better. 32:08.760 --> 32:14.360 Real life examples we've talked about. Let's showcase the capability. Let's use this website, 32:14.360 --> 32:18.360 send it out there, get the prototypes out there. We're talking about creating a fake 32:18.360 --> 32:24.720 company and just all their reports and so on, just so you can go through it and understand 32:24.720 --> 32:30.600 it. And let's address the fake news. Let's have those answers to those questions in terms 32:30.600 --> 32:38.120 of can anybody come up and delete everything and so on? Is my stuff safe, et cetera, et 32:38.120 --> 32:43.120 cetera? We've all heard it. Let's create those answers to it. 32:43.120 --> 32:56.120 So that is it from me. Thank you. Questions? Yes, sorry. Peter. 32:56.120 --> 33:00.120 Am I first? 33:00.120 --> 33:03.120 Yeah, go for it. 33:03.120 --> 33:10.880 I like your remark about the recipes. Discussed it with a couple of people over the days, 33:10.880 --> 33:18.440 especially Ike, who's not here today. He came up with some very good advice and I agree 33:18.440 --> 33:27.920 that if you install the Wiki from the box, you end up with that single white page and 33:27.920 --> 33:36.520 then you have to do something to create. And there are a lot of use cases, a lot of proven 33:36.520 --> 33:42.600 use cases that people create over and over again. And if it would be easier to install 33:42.600 --> 33:48.640 those as a basic functionality on top of your new fresh Wiki install, it would make it 33:48.640 --> 33:58.880 a lot easier for people to get started with making it a tailor-made solution for their 33:58.880 --> 34:08.160 own good. So things like having a document management system or having a list of events 34:08.160 --> 34:16.960 and a calendar or having a way of gathering personal data and creating contact lists and 34:16.960 --> 34:24.040 mailing lists or you name it. There are a couple of those basic functions that people 34:24.040 --> 34:33.400 might want to have in their Wiki. And if you can find a way to make those easily accessible 34:33.400 --> 34:42.480 and easy to install on a blank Wiki, that would be a great feature, I think, especially 34:42.480 --> 34:50.460 for people who are relatively new in the game and who haven't built up their own experience 34:50.460 --> 35:00.240 in the Wiki markup yet. And I came with an interesting suggestion that all it takes is 35:00.240 --> 35:10.000 to create the definitions for a set of properties, forms and templates and categories and you 35:10.000 --> 35:19.840 can easily import them in your Wiki as an XML file. So if you could build a website 35:19.840 --> 35:28.600 that hosts a couple of those examples and a user could download them in XML format and 35:28.600 --> 35:34.520 import them into their Wiki, they're set to go. So that is relatively easy. The only 35:34.520 --> 35:45.600 thing you need to do is to build those recipes and offer them to the public. 35:45.600 --> 35:55.640 Absolutely. And I think that's where the Enterprise Wiki website, we've discussed that, we should 35:55.640 --> 36:00.400 put down our suggestions for recipes and then prioritize them, all agree on a few, start 36:00.400 --> 36:05.360 creating them. So it almost becomes the app store for Media Wiki. 36:05.360 --> 36:17.040 Exactly. So if there is any interest of other people doing this, I'm happy to set up a little 36:17.040 --> 36:23.880 working group or a platform where a couple of people can exchange ideas about this and 36:23.880 --> 36:30.000 we can make this available in the open domain. 36:30.000 --> 36:39.560 Well I saw that you had a page owner and a page author. My experience with legal people 36:39.560 --> 36:45.800 is that they are very, they want everything to be casted in concrete and not to be touched 36:45.800 --> 36:53.000 anymore and it has to be perfect, unfortunately. So for them a Wiki is like it is always flowing 36:53.000 --> 37:01.080 around and it's never. I was wondering, do you also use an extension of closing, making 37:01.080 --> 37:06.280 a page not edible or flag revisions or something like that? 37:06.280 --> 37:10.120 So first of all I don't want to stop people going around and creating grammatical mistakes 37:10.120 --> 37:14.920 or so on. So we've said, absolutely do that. If you're not the author, if you're not being 37:14.920 --> 37:19.840 delegated an author of that page, you're not to change the content of that page. And that's 37:19.840 --> 37:27.040 a verbal thing. The administration of trying to lock them down and so on, I don't think 37:27.040 --> 37:34.040 the workload justifies the risk. Every day I look at the change logs and I think, I had 37:34.040 --> 37:37.760 a discussion with the NASA guys last night and they said in six and a half years they 37:37.760 --> 37:43.040 haven't had a problem. So there's a perception that could be an issue, but I don't think 37:43.040 --> 37:45.240 there is an issue. 37:45.240 --> 37:50.800 Anyone else? Oh, thank God. 37:50.800 --> 37:54.840 You mentioned analytics. Do you guys have something separate installed that... 37:54.840 --> 38:04.200 Yeah, I've forgotten the name. Mamonto, I think it's, I can't remember. It was Pyrrhic 38:04.200 --> 38:10.120 before and it's changed names recently. But yeah, that's the one we installed. 38:10.120 --> 38:15.840 It's watching and looking at click through links for where users are going or... 38:15.840 --> 38:21.840 Yeah, so to me the most powerful feature is understanding the route that people go through 38:21.840 --> 38:29.120 the Wiki. That's because it makes you wonder, why have you gone down that path? What's led 38:29.120 --> 38:35.400 you down that way? So yeah, but there's lots of other things, where the hits are, how often 38:35.400 --> 38:40.120 it's hit and what pages are most popular. And more importantly, what pages are never 38:40.120 --> 38:44.320 visited and why. Let's get rid of it then. 38:44.320 --> 39:07.760 Okay, I think no more questions. Excellent. Thank you very much.